home *** CD-ROM | disk | FTP | other *** search
ccccvvvvssss((((5555)))) XXXXEEEENNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((11112222 FFFFeeeebbbbrrrruuuuaaaarrrryyyy 1111999999992222)))) ccccvvvvssss((((5555)))) NNNNAAAAMMMMEEEE cvs - Concurrent Versions System support files SSSSYYYYNNNNOOOOPPPPSSSSIIIISSSS $$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT////CCCCVVVVSSSSRRRROOOOOOOOTTTT////mmmmoooodddduuuulllleeeessss,,,,vvvv $$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT////CCCCVVVVSSSSRRRROOOOOOOOTTTT////ccccoooommmmmmmmiiiittttiiiinnnnffffoooo,,,,vvvv $$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT////CCCCVVVVSSSSRRRROOOOOOOOTTTT////llllooooggggiiiinnnnffffoooo,,,,vvvv $$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT////CCCCVVVVSSSSRRRROOOOOOOOTTTT////rrrrccccssssiiiinnnnffffoooo,,,,vvvv $$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT////CCCCVVVVSSSSRRRROOOOOOOOTTTT////eeeeddddiiiittttiiiinnnnffffoooo,,,,vvvv $$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT////CCCCVVVVSSSSRRRROOOOOOOOTTTT////ccccvvvvssssiiiiggggnnnnoooorrrreeee,,,,vvvv $$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT////CCCCVVVVSSSSRRRROOOOOOOOTTTT////hhhhiiiissssttttoooorrrryyyy DDDDEEEESSSSCCCCRRRRIIIIPPPPTTTTIIIIOOOONNNN ccccvvvvssss is a system for providing source control to hierarchical collections of source directories. Commands and procedures for using ccccvvvvssss are described in ccccvvvvssss(1111). ccccvvvvssss manages _s_o_u_r_c_e _r_e_p_o_s_i_t_o_r_i_e_s, the directories containing master copies of the revision-controlled files, by copying particular revisions of the files to (and modifications back from) developers' private _w_o_r_k_i_n_g _d_i_r_e_c_t_o_r_i_e_s. In terms of file structure, each individual source repository is an im- mediate subdirectory of $$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT. The files described here are supporting files; they do not have to exist for ccccvvvvssss to operate, but they allow you to make ccccvvvvssss operation more flexible. The ccccvvvvssssiiiinnnniiiitttt(1111) shell script included at the top-level of the ccccvvvvssss distribution can be used to setup an initial $$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT////CCCCVVVVSSSSRRRROOOOOOOOTTTT area, if you don't have one already. You can use the `modules' file to define symbolic names for collections of source maintained with ccccvvvvssss. If there is no `modules' file, developers must specify complete path names (absolute, or relative to $$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT) for the files they wish to manage with ccccvvvvssss commands. You can use the `commitinfo' file to define programs to exe- cute whenever `ccccvvvvssss ccccoooommmmmmmmiiiitttt' is about to execute. These pro- grams are used for ``pre-commit'' checking to verify that the modified, added, and removed files are really ready to be committed. Some uses for this check might be to turn off a portion (or all) of the source repository from a particu- lar person or group. Or, perhaps, to verify that the changed files conform to the site's standards for coding Page 1 (printed 7/8/94) ccccvvvvssss((((5555)))) XXXXEEEENNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((11112222 FFFFeeeebbbbrrrruuuuaaaarrrryyyy 1111999999992222)))) ccccvvvvssss((((5555)))) practice. You can use the `loginfo' file to define programs to execute after any ccccoooommmmmmmmiiiitttt, which writes a log entry for changes in the repository. These logging programs might be used to ap- pend the log message to a file. Or send the log message through electronic mail to a group of developers. Or, perhaps, post the log message to a particular newsgroup. You can use the `rcsinfo' file to define forms for log mes- sages. You can use the `editinfo' file to define a program to exe- cute for editing/validating `ccccvvvvssss ccccoooommmmmmmmiiiitttt' log entries. This is most useful when used with a `rcsinfo' forms specifica- tion, as it can verify that the proper fields of the form have been filled in by the user committing the change. You can use the `cvsignore' file to specify the default list of files to ignore during uuuuppppddddaaaatttteeee. You can use the `history' file to record the ccccvvvvssss commands that affect the repository. The creation of this file en- ables history logging. FFFFIIIILLLLEEEESSSS mmmmoooodddduuuulllleeeessss The `modules' file records your definitions of names for collections of source code. ccccvvvvssss will use these de- finitions if you create a file with the right format in `$$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT////CCCCVVVVSSSSRRRROOOOOOOOTTTT////mmmmoooodddduuuulllleeeessss,,,,vvvv'. The mmmmkkkkmmmmoooodddduuuulllleeeessss(1111) command should be run whenever the modules file changes, so that the appropriate files can be generated (depending on how you have configured ccccvvvvssss operation). To allow convenient editing of the `modules' file it- self, the file should include an entry like the follow- ing (where _l_o_c_a_l_b_i_n represents the directory where your site installs programs like mmmmkkkkmmmmoooodddduuuulllleeeessss(1111)): mmmmoooodddduuuulllleeeessss ----iiii ////_l_o_c_a_l_b_i_n////mmmmkkkkmmmmoooodddduuuulllleeeessss CCCCVVVVSSSSRRRROOOOOOOOTTTT mmmmoooodddduuuulllleeeessss This defines the name `mmmmoooodddduuuulllleeeessss' as the module name for the file itself, so that you can use eeeexxxxaaaammmmpppplllleeee%%%% ccccvvvvssss cccchhhheeeecccckkkkoooouuuutttt mmmmoooodddduuuulllleeeessss to get an editable copy of the file. You should define similar module entries for the other configuration files described here (except `history'). The ccccvvvvssssiiiinnnn---- iiiitttt(1111) script will setup a smilar `modules' file for you automatically. Page 2 (printed 7/8/94) ccccvvvvssss((((5555)))) XXXXEEEENNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((11112222 FFFFeeeebbbbrrrruuuuaaaarrrryyyy 1111999999992222)))) ccccvvvvssss((((5555)))) The `modules' file may contain blank lines and comments (lines beginning with `####') as well as module defini- tions. Long lines can be continued on the next line by specifying a backslash (``\'') as the last character on the line. A _m_o_d_u_l_e _d_e_f_i_n_i_t_i_o_n is a single line of the `modules' file, in either of two formats. In both cases, _m_n_a_m_e represents the symbolic module name, and the remainder of the line is its definition. _m_n_a_m_e ----aaaa _a_l_i_a_s_e_s... This represents the simplest way of defining a module _m_n_a_m_e. The `----aaaa' flags the definition as a simple alias: ccccvvvvssss will treat any use of _m_n_a_m_e (as a command argument) as if the list of names _a_l_i_a_s_e_s had been specified instead. _a_l_i_a_s_e_s may contain either other module names or paths. When you use paths in _a_l_i_a_s_e_s, `ccccvvvvssss cccchhhheeeecccckkkkoooouuuutttt' creates all intermediate directories in the working directory, just as if the path had been specified explicitly in the ccccvvvvssss arguments. _m_n_a_m_e [ _o_p_t_i_o_n_s ] _d_i_r [ _f_i_l_e_s... ] [ &&&&_m_o_d_u_l_e... ] In the simplest case, this form of module definition reduces to `_m_n_a_m_e _d_i_r'. This defines all the files in directory _d_i_r as module _m_n_a_m_e. _d_i_r is a relative path (from $$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT) to a directory of source in one of the source repositories. In this case, on cccchhhheeeecccckkkkoooouuuutttt, a sin- gle directory called _m_n_a_m_e is created as a working directory; no intermediate directory levels are used by default, even if _d_i_r was a path involving several directory levels. By explicitly specifying _f_i_l_e_s in the module definition after _d_i_r, you can select particular files from direc- tory _d_i_r. The sample definition for mmmmoooodddduuuulllleeeessss is an ex- ample of a module defined with a single file from a particular directory. Here is another example: mmmm4444tttteeeesssstttt uuuunnnnssssuuuuppppppppoooorrrrtttteeeedddd////ggggnnnnuuuu////mmmm4444 ffffoooorrrreeeeaaaacccchhhh....mmmm4444 ffffoooorrrrlllloooooooopppp....mmmm4444 With this definition, executing `ccccvvvvssss cccchhhheeeecccckkkkoooouuuutttt mmmm4444tttteeeesssstttt' will create a single working directory `m4test' con- taining the two files listed, which both come from a common directory several levels deep in the ccccvvvvssss source repository. A module definition can refer to other modules by in- cluding `&&&&_m_o_d_u_l_e' in its definition. cccchhhheeeecccckkkkoooouuuutttt creates a subdirectory for each such _m_o_d_u_l_e, in your working directory. Page 3 (printed 7/8/94) ccccvvvvssss((((5555)))) XXXXEEEENNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((11112222 FFFFeeeebbbbrrrruuuuaaaarrrryyyy 1111999999992222)))) ccccvvvvssss((((5555)))) _N_e_w _i_n ccccvvvvssss _1._3; avoid this feature if sharing module definitions with older versions of ccccvvvvssss. Finally, you can use one or more of the following _o_p_- _t_i_o_n_s in module definitions: `----dddd _n_a_m_e', to name the working directory something oth- er than the module name. _N_e_w _i_n ccccvvvvssss _1._3; avoid this feature if sharing module definitions with older versions of ccccvvvvssss. `----iiii _p_r_o_g' allows you to specify a program _p_r_o_g to run whenever files in a module are committed. _p_r_o_g runs with a single argument, the full pathname of the af- fected directory in a source repository. The `commi- tinfo', `loginfo', and `editinfo' files provide other ways to call a program on ccccoooommmmmmmmiiiitttt. `----oooo _p_r_o_g' allows you to specify a program _p_r_o_g to run whenever files in a module are checked out. _p_r_o_g runs with a single argument, the module name. `----tttt _p_r_o_g' allows you to specify a program _p_r_o_g to run whenever files in a module are tagged. _p_r_o_g runs with two arguments: the module name and the symbolic tag specified to rrrrttttaaaagggg. `----uuuu _p_r_o_g' allows you to specify a program _p_r_o_g to run whenever `ccccvvvvssss uuuuppppddddaaaatttteeee' is executed from the top-level directory of the checked-out module. _p_r_o_g runs with a single argument, the full path to the source repository for this module. ccccoooommmmmmmmiiiittttiiiinnnnffffoooo, llllooooggggiiiinnnnffffoooo, rrrrccccssssiiiinnnnffffoooo, eeeeddddiiiittttiiiinnnnffffoooo These files all specify programs to call at different points in the `ccccvvvvssss ccccoooommmmmmmmiiiitttt' process. They have a common structure. Each line is a pair of fields: a regular expression, separated by whitespace from a filename or command-line template. Whenever one of the regular ex- pression matches a directory name in the repository, the rest of the line is used. If the line begins with a #### character, the entire line is considered a comment and is ignored. Whitespace between the fields is also ignored. For `loginfo', the rest of the line is a command-line template to execute. The templates can include not only a program name, but whatever list of arguments you wish. If you write `%%%%ssss' somewhere on the argument list, ccccvvvvssss supplies, at that point, the list of files affected by the ccccoooommmmmmmmiiiitttt. The first entry in the list is the relative path within the source repository where Page 4 (printed 7/8/94) ccccvvvvssss((((5555)))) XXXXEEEENNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((11112222 FFFFeeeebbbbrrrruuuuaaaarrrryyyy 1111999999992222)))) ccccvvvvssss((((5555)))) the change is being made. The remaining arguments list the files that are being modified, added, or removed by this ccccoooommmmmmmmiiiitttt invocation. For `commitinfo', the rest of the line is a command- line template to execute. The template can include can include not only a program name, but whatever list of arguments you wish. The full path to the current source repository is appended to the template, followed by the file names of any files involved in the commit (added, removed, and modified files). For `rcsinfo', the rest of the line is the full path to a file that should be loaded into the log message tem- plate. For `editinfo', the rest of the line is a command-line template to execute. The template can include can in- clude not only a program name, but whatever list of ar- guments you wish. The full path to the current log message template file is appended to the template. You can use one of two special strings instead of a regular expression: `AAAALLLLLLLL' specifies a command line tem- plate that must always be executed, and `DDDDEEEEFFFFAAAAUUUULLLLTTTT' specifies a command line template to use if no regular expression is a match. The `commitinfo' file contains commands to execute _b_e_- _f_o_r_e any other ccccoooommmmmmmmiiiitttt activity, to allow you to check any conditions that must be satisfied before ccccoooommmmmmmmiiiitttt can proceed. The rest of the ccccoooommmmmmmmiiiitttt will execute only if all selected commands from this file exit with exit status 0000. The `rcsinfo' file allows you to specify _l_o_g _t_e_m_p_l_a_t_e_s for the ccccoooommmmmmmmiiiitttt logging session; you can use this to provide a form to edit when filling out the ccccoooommmmmmmmiiiitttt log. The field after the regular expression, in this file, contains filenames (of files containing the logging forms) rather than command templates. The `editinfo' file allows you to execute a script _b_e_- _f_o_r_e _t_h_e _c_o_m_m_i_t _s_t_a_r_t_s, but after the log information is recorded. These "edit" scripts can verify informa- tion recorded in the log file. If the edit script ex- its wth a non-zero exit status, the commit is aborted. The `loginfo' file contains commands to execute _a_t _t_h_e _e_n_d of a commit. The text specified as a commit log message is piped through the command; typical uses in- clude sending mail, filing an article in a newsgroup, Page 5 (printed 7/8/94) ccccvvvvssss((((5555)))) XXXXEEEENNNNIIIIXXXX SSSSyyyysssstttteeeemmmm VVVV ((((11112222 FFFFeeeebbbbrrrruuuuaaaarrrryyyy 1111999999992222)))) ccccvvvvssss((((5555)))) or appending to a central file. ccccvvvvssssiiiiggggnnnnoooorrrreeee, ....ccccvvvvssssiiiiggggnnnnoooorrrreeee The default list of files (or sssshhhh(1111) file name patterns) to ignore during `ccccvvvvssss uuuuppppddddaaaatttteeee'. At startup time, ccccvvvvssss loads the compiled in default list of file name pat- terns (see ccccvvvvssss(1111)). Then the per-repository list in- cluded in $$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT////CCCCVVVVSSSSRRRROOOOOOOOTTTT////ccccvvvvssssiiiiggggnnnnoooorrrreeee is loaded, if it exists. Then the per-user list is loaded from `$HOME/.cvsignore'. Finally, as ccccvvvvssss traverses through your directories, it will load any per-directory `.cvsignore' files whenever it finds one. These per- directory files are only valid for exactly the directo- ry that contains them, not for any sub-directories. hhhhiiiissssttttoooorrrryyyy Create this file in $$$$CCCCVVVVSSSSRRRROOOOOOOOTTTT////CCCCVVVVSSSSRRRROOOOOOOOTTTT to enable history logging (see the description of `ccccvvvvssss hhhhiiiissssttttoooorrrryyyy'). SSSSEEEEEEEE AAAALLLLSSSSOOOO ccccvvvvssss(1111), mmmmkkkkmmmmoooodddduuuulllleeeessss(1111). CCCCOOOOPPPPYYYYIIIINNNNGGGG Copyright c 1992 Cygnus Support, Brian Berliner, and Jeff Polk Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this per- mission notice are preserved on all copies. Permission is granted to copy and distribute modified ver- sions of this manual under the conditions for verbatim copy- ing, provided that the entire resulting derived work is dis- tributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above condi- tions for modified versions, except that this permission no- tice may be included in translations approved by the Free Software Foundation instead of in the original English. Page 6 (printed 7/8/94) 
